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INTERFACE  PROTOCOL  REQUIREMENTS 
FOR  SHIPBOARD  DAMAGE  CONTROL  SYSTEMS 


INTRODUCTION 

One  of  the  goals  of  current  research  in  the  field  of  shipboard  danid^c  cuimoi  is  to  liave  the  ability  to 
detect,  transmit,  analyze,  and  display  damage  control  (DC)  information  quickly  and  effectively  in  order  to 
expedite  corrective  actions.  An  important  part  of  this  research  is  the  development  of  advanced  sensors  that 
will  provide  more  precise,  detailed,  and  complex  sensor  information,  and  have  the  ability  to  modify  or  re¬ 
configure  the  sensor’s  operational  characteristics.  Shipboard  sensors  for  smoke,  heat,  flame,  fire  classifi¬ 
cation,  flooding,  hull  damage,  and  chemical,  biological,  and  radiological  (CBR)  agents  are  under  develop¬ 
ment  that  will  provide  detailed  information  pertaining  to  the  specific  characteristics  of  the  threat  [1].  This 
influx  of  information  must  be  managed  effectively  both  at  the  operator’s  console  and  among  the  circuits 
connecting  the  various  devices. 

As  the  number  and  sophistication  of  advanced  sensors  increase,  significant  changes  will  be  made  to  the 
methods  of  displaying  the  information,  and  to  the  methods  of  connecting  sensors  to  control  and  display  de¬ 
vices.  The  use  of  computer  woiicstations  with  graphical  displays  has  become  commonplace  in  office  envi- 
ronm.ents,  and  work  has  been  perfonned  on  developing  these  same  graphical  techniques  for  shipboard 
damage  control  [2].  An  effective  means  of  managing  information,  displaying  data,  and  controlling 
equipment  is  the  use  of  graphical  user  interface  techniques.  This  approach  is  very  effective  in  reducing  the 
information-processing  burden  of  the  operator;  it  allows  the  operator  to  retrieve  the  information  when  it  is 
needed. 

Changes  to  the  methods  of  connecting  sensors  to  control/display  devices,  and  the  mechanisms  by 
which  sensor  information  is  transferred  will  also  be  required.  Network  architectures  for  system  and  device 
interconnect  is  the  current  trend,  and  this  trend  is  expected  to  continue  for  the  foreseeable  future.  To  use 
networking  effectively,  a  coherent  method  of  transferring  DC  information  across  these  networks  is  needed. 
This  method  of  information  transfer  is  the  interface  protocol,  and  it  comprises  not  only  the  information 
being  transferred,  but  also  the  rules  by  which  transactions  between  devices  are  conducted.  This  report 
presents  the  requirements  and  recommendations  for  a  baseline  implementation  of  this  protocol. 

DAMAGE  CONTROL  SYSTEM  ARCHITECTURE 

An  important  consideration  in  the  design  of  any  system  that  has  remote  sensing  capabilities  is  the  sys¬ 
tem  architecture,  or  method  of  connecting  the  various  devices  to  each  other.  Most  damage  control  seasors 
are  connected  to  alarm  systems  that  operate  locally  or  through  point-to-point  connections  to  Damage  Control 
Central  (DCQ  or  one  of  the  ship's  Repair  Stations.  This  centralized  architecture  is  satisfactory  for  small 
systems,  but  it  becomes  unduly  complicated  for  widely  dispersed  systems  that  have  a  large  number  of 


Manuscript  approved  September  25,  1992. 


1 


D.  TATE 


sensors.  For  these  systems,  an  architecture  where  sensors  and  equipment  are  distributed  along  a  shared 
network  provides  a  more  flexible  and  expandable  system. 

Centralized  Architecture 

In  a  centralized  DC  architecture,  the  equipment  and  sensors  for  damage  control  and  hull,  mechanical 
and  electrical  (HM&E)  systems  are  connected  to  a  central  processing  system  (Fig.  1).  The  processing  can 
be  performed  by  a  device  as  simple  as  a  lighted  pushbutton  control  panel  or  by  a  more  complex  system  such 
as  a  state-of-the-art  computer.  In  either  case,  all  of  the  sensors  have  a  direct  interface  to  the  processor.  This 
architecture  has  been  used  in  the  past,  where  sensors  are  connected  directly  to  control  panels  in  DCC  or  one 
of  the  ship's  Repair  Stations. 


<Jimperature]> 


,Smoke^ 


C^^anual  Aiarm]^ 


(HM&iy 


\  I  ^ 

DC  Central  or 
Repair  Station 
Control  Panel 


Flame 


CRate  of  Ris^ 


/  \ 


C^W^erlalr  Flow^  C^^tch  Closure]];> 


Fig.  1  —  Centralized  architectures  are  characterized  by  a  central  processing  station  to 
which  all  sensors  are  directly  connected.  This  architecture  has  several  drawbacks  which 
make  it  unsuitable  for  future  damage  control  systems. 


A  centralized  architecture  has  several  drawbacks.  One  is  the  long,  elaborate  wiring  systems  required  to 
connect  each  sensor  to  the  control  panel.  Sensors  are  located  throughout  the  ship,  and  each  one  requires  a 
separate,  dedicated  circuit  to  the  control  panel.  With  a  large  number  of  sensors  on  board,  and  multiple 
sensors  located  in  many  spaces,  redundant  cabling  is  commonplace  between  DCC  and  vital  areas. 
Complicated  wire  runs  across  and  between  decks  are  often  used  to  reduce  the  length  of  these  cables.  The 
weight  of  the  wiring  alone  for  large  systems  can  be  substantial,  even  prohibitive. 

Another  drawback  of  the  centralized  architecture  is  that  several  single  points  of  failure  exist.  A  system 
failure  resulting  from  failure  of  the  central  processor  is  an  obvious  deficiency.  If  the  control  panel  in  DCC 
fails,  all  the  .sen.sors  that  are  connected  to  it  are  useless.  Tlie  sensors  may  be  functioning  perfectly,  but 
without  a  means  of  displaying  their  status,  they  provide  no  help  to  DC  personnel.  The  cabling  that  provides 
the  circuit  between  the  sensor  and  DCC  is  another  point  of  failure.  Because  some  of  these  cables  arc 
necessarily  long,  damage  to  a  part  of  the  cable  that  is  not  located  near  the  seasor  nor  near  DCC  could  cau.se 
the  loss  of  seasor  information.  In  situations  where  multiple  cables  share  a  common  conduit  or  raceway,  the 
loss  of  u.se  of  many  detectors  can  be  caused  by  damage  occurring  nowhere  near  the  sensors  or  the  control 
panel. 
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This  architecture  also  has  limited  flexibility.  Relocating  the  control  panel  is  virtually  impossible,  since 
it  would  require  rerouting  all  the  cabling  from  the  sensors.  Since  the  control  panel  cannot  be  moved,  the 
compartment  where  it  is  located  must  be  manned  at  all  times.  Although  damage  control  sensors  are  moni¬ 
tored  at  all  times  anyway,  other  architectures  provide  ways  to  perform  monitoring  from  alternate  locations. 
With  a  centralized  architecture,  if  DCC  must  be  evacuated,  the  sensors  and  displays  may  continue  to  operate 
perfectly,  but  DC  personnel  will  have  no  access  to  the  information. 

Expandability  of  a  centralized  architecture  is  also  a  problem.  The  control  panel  interfaces  must  be  de¬ 
signed  to  accommodate  all  current  capabilities  and  any  anticipated  expansion.  Multiplexing  techniques  can 
reduce  the  effect  of  having  to  add  new  components  to  the  system,  but  new  cabling  to  new  sensors  is  still 
required.  Running  a  single  cable  from  DCC  to  a  new,  remotely  located  sensor  may  be  a  difficult  task  in  it¬ 
self. 


Centralized  architectures  are  usually  sufficient  for  small  systems,  but  new  Navy  ships  have  far  too  may 
sensors  to  be  able  to  use  this  architecture  in  the  fumre. 

Distributed  Architecture 

To  meet  the  needs  of  future  systems,  an  architecture  that  supports  sensors  and  equipment  that  arc  dis¬ 
tributed  along  a  shared  network  is  required.  This  distributed  architecture  typically  uses  a  local  area  network 
(LAN)  to  which  sensors,  alarms,  control  panels,  or  operator  workstations  can  be  connected  (Fig.  2).  The 
specific  attributes  o^  the  LAN  can  be  chosen  from  a  variety  of  media,  topologies,  transmission  speeds,  and 
network  management  schemes.  Through  appropriate  LAN  interfaces,  devices  can  be  accessed  by  using 
standard  LAN  access  techniques  that  do  not  require  a  specific  layout  or  interconnection  scheme. 


C^nual  Alarm^ 

\ 


C]]Senso7^ 

J  (Area  alarms) 
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Workstation 


^  ^  I  Local  I 

V  Area  I 

Network 

tiOn  I  ^ 


Control  Panel 


CH^sor^ 


Workstation 


Fig.  2  —  Distributed  architectures  support  sensors  and  equipment  that  are  distributed  along  a  shared  local 
area  network  (LAN).  This  architecture  provides  the  flexibility  and  expandability  needed  for  future 
damage  control  systems. 


The  distributed  architecture  provides  much  more  flexibility  than  the  centralized  architecture.  A  typical 
installation  would  have  the  LAN  installed  throughout  the  ship,  with  access  available  through  relatively  short 
“drops”  to  various  devices.  Bccau.se  of  the  distributed  nature  of  the  LAN,  devices  can  be  located  anywhere 
along  the  network  and  can  be  relocated,  added,  or  removed  with  little  effort.  The  addition  of  a  new  sensor 
would  require  laying  only  the  “drop”  cable  from  the  sensor  to  the  LAN.  The  diagram  in  Fig.  2  assumes  that 
sensors  have  their  own  built-in  LAN  interfaces,  which  will  not  be  the  case  where  new  DC  systems  arc  being 
backfitted  onto  older  ships  with  stand-alone  .sensors.  To  accommodate  these  older  designs,  LAN 
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multiplexer/interface  units  can  provide  the  necessary  connection  to  the  LAN  (Fig.  3).  These  units  can 
provide  sensor  monitoring  functions  and  LAN  access  for  multiple  sensors  of  various  types. 

The  distributed  architecture  is  easily  expanded  by  simply  providing  LAN  interfaces  to  the  new  devices. 
Access  to  shipboard  database  systems  via  the  LAN  would  be  especially  helpful  to  DC  personnel.  Through 
these  databases,  information  such  as  ship’s  diagrams,  maintenance  schedules,  equipment  inventories,  duty 
rosters,  and  numerous  other  types  of  information  would  be  available.  Even  access  to  other  ship  systems 
located  on  other  LANs  can  be  attained  by  using  network  gateways.  These  devices  perform  the  traffic 
management  and  translation  of  protocols  to  allow  devices  on  different  nctworics  to  share  resources. 


CSl^ricl-alone  sensors 


C3^nd-alone  senso^^ 


C3^nd-alone  sensors^ 


Other  networks,  resources,  or  services 


Fig.  3  —  Distributed  architectures  can  provide  increased  capabilities  through  access  to  networked 
databases,  computer  workstations,  and  other  networks,  resources,  and  services.  LAN 
multiplexer/interface  units  can  provide  the  necessary  interfaces  to  existing  sensors  to  meet  backfit 
requirements. 

The  di.stributed  architecture  also  reduces  the  susceptibility  to  a  single  point  of  failure.  Obviously  a 
failure  of  the  LAN  would  have  catastrophic  implications,  but  techniques  are  available  to  en.sure  its  sur¬ 
vivability.  Redundant,  survivable  networks  can  be  designed  so  that  damage  to  any  part  of  the  LAN  can  be 
compensated  for  by  alternate  routing  paths.  Network  management  algorithms  keep  track  of  network 
connectivity  and  routes  between  devices  and  dynamically  adapt  for  problems.  This  is  standard  practice  on 
mission-critical  systems  that  use  this  type  of  architecture.  The  five-bus  Data  Multiplexing  System  used  on 
the  DDG-5 1  class  destroyers  [3]  exemplifies  the  use  of  redundant,  survivable  networks  for  damage  control. 

Distributed  network  architectures  arc  common  in  various  computer-based  systems  and  will  continue  to 
be  used  for  the  foreseeable  future.  New  systems  de.signed  for  damage  control,  including  the  Integrated 
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Survivability  Management  System  (ISMS)  [4]  will  use  this  architecture  to  meet  the  requirements  of  future 
DC  systems. 

Information  Processing  Structure 

Our  EXT  system  architecmre  uses  an  information-processing  structure  that  can  be  divided  into  three  sep¬ 
arate  areas — sensor  development,  transfer  protocol  development,  and  console/display  development  (Fig.  4). 
Sensor  development  addresses  the  research  of  new  methods  for  sensing  and  measuring  damage  control 
parameters,  providing  the  necessary  mechanisms  for  reading  the  sensor  data,  and  providing  *'  ntcrfaccs 
for  monitoiing  and  controlling  sensor  performance.  Transfer  protocol  development  addresses  the 
formulation  of  techniques  for  transferring  sensor  data  from  sensors  to  consoles,  and  the  development  of 
procedures  and  rules  for  managing  data  transfer  transactions.  Console/display  development  pertains  to  the 
development  of  methods  of  displaying  information  graphically,  providing  operator  interaction  through 
graphical  input  techniques,  and  filtering  raw  sensor  data  to  provide  more  concise  information  to  the 
operator.  Figure  4  s'rows  the  functional  areas  of  the  information  processing  structure,  which  may  differ 
from  the  physical  construction.  For  example,  the  multiplexer  interface  unit  described  above  may  include 
both  the  seasor  interface  and  LAN  interface  functions. 


Sensor  readings  Sensor  status  LAN  User 

&  control  data  data  Information 

&  actions 


Sensor  development  Transfer  protocol  development  Console/display  development 

Fig.  4  —  Information  processing  structure  for  damage  control  workstations 

NETWORK  DESIGN  ISSUES 

Distributed  architectures  can  be  implemented  by  using  various  types  of  LAN  designs.  Equivalent 
capabilities  can  be  acquired  from  various  media,  topologies,  and  management  techniques.  The  particular 
characteristics  of  the  network  must  be  transparent  to  the  damage  control  systems  so  that  they  can  operate  in 
different  environments,  and  even  between  different  types  of  networks,  if  needed. 
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Media  Types 

A  wide  variety  of  transmission  media  are  available  for  data  communications  and  networking  [5 1.  The 
media  types  available  for  damage  control  systems  include  twisted-pair  cables,  coaxial  and  twin  coaxial  ca¬ 
bles,  CATV  circuits,  and  optical  fiber  circuits.  Each  medium  has  advantages  and  disadvantages,  and 
shipboard  systems  may  comprise  a  combination  of  media.  Mixed  media  i.-*  common  in  some  laboratorc  cn 
vironments  where  networks  may  use  twisted-pair  cables  fe.g.,  LocalTalk,  RS-422,  or  Ethernet  IdBascT), 
coaxial  cables  (e.g.,  Ethernet  10Base2  and  10Base5),  optical  fibers  (e.g.,  FDDI,  SAEENET  II,  or 
SONET).  CATV  systems  (also  referred  to  as  broadband  systems)  can  provide  multiple  separate  networks 
through  a  common  cable  iastead  of  duplicate  cabling  to  achieve  network  isolation.  CATV  techniques  would 
also  permit  standard  video  signals  to  be  used  on  some  channels  to  allow  shipboard  cameras  to  share  the 
same  cable  as  the  data  communications  systems.  The  NRL  Integrated  Communications  Environment 
Network  (NICENET)  [6|  is  a  good  example  of  a  communications  network  that  connecLs  various  types  of 
media,  data  sources,  and  video  sources  into  an  integrated  broadband  system. 

Because  of  the  tendency  to  mix  transmission  media  types  within  a  network  environment,  and  because 
more  advanced  technology  media  arc  always  under  development,  care  must  be  taken  when  designing  DC 
systems  so  that  the  capabilities  of  the  system  arc  not  dependent  on  any  particular  medium.  This  generally  is 
not  a  problem  if  standard  network  access  schemes  arc  followed.  Methods  for  tran.smitting  and  receiving 
data  on  the  network  medium  arc  generally  hidden  from  the  application  program  by  providing  higher  level 
routines  for  supplying  or  accepting  data.  This  allows  the  programs  to  transfer  data  across  the  network 
without  having  to  know  the  details  of  the  network  design.  Damage  control  application  programs  must  not 
bypass  these  routines  to  gain  direct  access  to  the  net,  since  such  techniques  may  cause  the  program  to  fail  if 
the  network  medium  is  changed. 

Network  Topologies 

There  arc  many  different  possibilities  for  the  topological  structure  of  a  netw  ork — ranging  in  complexity 
from  small,  simple  structures  to  mixed,  complex  hierarchical  designs.  Figure  5  show  s  examples  of  some  of 
the  totxilogy  tvnes.  The  star  topology  is  a  centralized  configuration  where  network  control  is  administered 
by  the  star  controller  to  which  all  network  devices  (or  nodc.s)  arc  connected.  All  data  arc  transmitted  to  tmd 
received  from  the  star  controller,  and  the  controller  handles  all  network  management  functions.  Devices 
have  uncontested  access  to  the  medium,  but  they  compete  for  procc.ssing  time  in  the  controller.  In  a  single- 
controller  configuration,  the  network  becomes  a  centralized  architecture  having  the  inherent  problems 
de.scribcd  above 


The  bus  topology  uses  a  common  shared  medium  that  is  distributed  to  all  locatioas  requiring  access  to 
tfie  network.  Traffic  management  is  not  centrally  controlled  but  is  distributed  among  all  the  devices  through 
well-defined  network-access  procedures.  Contention  for  use  of  the  medium  can  be  a  problem  here,  but  un¬ 
contested  transmissions  arc  immediate  and  direct.  To  handle  contention  problems,  each  device  must  have 
the  ability  to  determine  whether  or  not  the  network  is  busy,  and  whcilicr  or  not  its  u.se  of  the  net  was  suc¬ 
cessful.  Carrier-sensed  multiple  access  with  collision  detection  (CSMA/CD)  that  is  used  on  Ethernet  is  an 
example  of  one  technique  to  determine  medium  availability  (through  sensing  the  carrier)  and  transmission 
success  (through  collision  detection)  in  networks  using  a  bus  topology. 

In  the  ring  topology,  devices  arc  connected  only  to  their  immediate  neighbor  in  tltc  network.  Data  be¬ 
ing  transmitted  to  distant  devices  are  pa.sscd  from  device  to  device  until  they  reach  their  de.stination.  The  to¬ 
tal  amount  of  cabling  can  be  .smaller  titan  with  other  topologies,  but  additional  delay  may  be  created  if  data 
must  pa.ss  through  a  large  number  of  intermediate  nodes.  Tltc  Survivablc  Adaptable  Fiber  Optic  Embedded 
Network  II  (S.AFENET  II)  [7|  is  an  example  of  a  topology  tliat  uses  dual  Fiber  Distributed  Data  Interface 
(FDDI)  token  ring  LANs. 


6 


NRI  REPORT  9525 


Star 


•  ••  O 

•  •  •  • 


Bus 


Fig.  5  —  Example  topological  layouts  for  networks 


Mixed  topologies  arc  often  used  when  networks  of  different  topologies  arc  connected  to  form  an 
internet.  This  connection  is  accomplished  through  a  gateway  that  performs  the  necessary  media  and 
protocol  conversions  to  allow  the  networks  to  interact  with  each  other. 

Data  Transmission  vSpeed 

The  need  for  faster  transmission  speeds  to  support  the  transfer  of  large  amounts  of  data  has  led  to  a 
progression  from  twisted-pair  wiring  to  coaxial  cables  to  optical  fibers  for  high-speed  networks.  The  speed 
at  which  a  network  can  transfer  data  is  determined  in  part  by  the  type  of  medium  used,  but  delay  and 
throughput  affect  speed  regardless  of  the  medium.  Delay  can  be  defined  as  the  lime  between  the  transmis¬ 
sion  of  the  first  bit  of  information  from  the  source  to  the  lime  of  its  delivery  to  the  de.stinaiion.  Delay  is 
usually  measured  as  average  response  time  and  is  affected  by  circuit  data  rate,  processing  delay  times, 
queuing  delay  times,  and  system  load.  Because  of  the  mi.ssion-criiical  nature  of  damage  control  sensor  in- 
fomidtion,  it  is  imperative  that  the  network  through  which  this  data  is  transferred  have  a  very  low  delay 
time.  Data  nctwork.s  that  arc  designed  for  large  data  transfers  with  little  concern  tor  long  delay  times  arc  not 
suitable  for  damage  control  use.  Use  of  shared  data  networks  with  low  delay  times  could  be  used  if  DC 
information  could  preempt  other  data  through  prioritization.  Gateways  that  block  unnecessary  traffic  from 
the  damage  control  net  may  be  required  in  coru'iguraiioas  where  intcnict  connccticrct  arc  permitted. 

Throughput  is  defined  as  the  number  of  bits  .sent  divided  by  the  time  between  transmission  of  the  first 
bit  and  delivery  of  the  la.st  bit.  Throughput  is  primarily  dctcimincd  by  the  effective  bandwidth  of  the 
processing  equipment  and  transmission  medium.  High  throughput  is  most  often  required  in  data  networks 
for  functions  such  as  file  transfer,  but  in  shipboard  damage  control  systems  the  high  peak  loads  caused  by 
ca.sualty  situations  can  create  large  amounts  of  data  that  must  be  handled  quickly.  High  throughput  is 
required  to  prevent  system  overload  resulting  from  a  large  number  of  alarm  conditions,  as  would  occur  in  a 
major  conflagration. 

Network  Management 

For  distributed  damage  control  systems  to  work  effectively,  the  underlying  network  management  must 
be  handled  transparenrly  with  no  active  participation  by  the  damage  control  applications.  The  application 
programs  must  be  designed  to  pass  information  via  data  packets  to  the  network  management  modules, 
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which  in  tii’”  -crfom  all  the  functions  necessary  to  assure  reliable  transfer  of  information  between  devices. 
The  ne:"  .ic  management  functions  include  reliable  data  delivery,  packet  routing,  assured  network 
connectivity,  and  communications  security. 

R/nnin;^ 


Devices  on  a  distnbuted  network  usually  have  multiple  routes  tliat  tliey  can  u.se  to  transfer  data  b>.'twccn 
sources  and  destinations.  The  route  that  any  particular  data  packet  traverses  must  be  unknown  to  the  appli¬ 
cation  program  but  known  by  the  network  management  .software.  This  separation  of  function  permits 
changes  to  be  m.ade  to  the  network  with  no  moditlcations  necessary  to  the  application  program.  Large 
blocks  of  data  may  actually  be  divided  into  smaller  packets,  and  separate  routing  for  the.se  packets  ma>  be 
used  to  provide  faster  throughput.  Routing  algonthms  can  select  the  fa.stest  route  to  u.se  between  source  and 
destination,  and  can  perform  dynamic  adjustments  to  routing  schemes  ba.sed  on  system  load,  subnet  trans¬ 
mission  speed,  queue  si/e,  and  link  integnty.  The  application  program  must  not  rely  on  any  particular 
routing  scheme  for  reliable  operation,  and  it  must  not  circumvent  network  management  funciinns  in  an  at¬ 
tempt  to  achieve  higher  perfomiance. 

RdiiihUity 

Reliability  of  the  network  is  roquired  in  two  distinct  areas.  Data  delivery  reliability  is  die  assurance  by 
the  network  management  software  that  information  from  the  source  device  is  received  without  error  at  the 
destination  device.  Error  detection  and  correction  techniques  of  vanous  types  arc  used  to  assure  deliverv . 
and  they  may  be  used  at  vanous  stages  of  the  transfer  proce.ss.  .Application  programs  can  assume  that 
completed  data  iransmi.ssion  means  error-free  delivery,  but  Ltiey  must  not  assume  that  any  specific  technique 
or  transmission  speed  is  used  to  assure  delivery.  Even  in  very  high-speed  networks,  delays  can  he  iiKurred 
dunng  peak  loads  that  affect  transmission  speed  but  not  transmission  reliability.  Care  must  be  taken  to  de¬ 
sign  application  programs  that  do  not  require  immediate  reply  from  any  particular  device  on  the  network, 
since  some  data  delivery  schemes  cannot  provide  a  guaranteed  traasmission  time. 

.Another  aspect  of  network  reliability  that  is  required  by  damage  control  sy  stems  is  the  assurance  of 
network  integnty.  {3ecau.se  DC  systems  arc  designed  to  combat  damage,  the  network  it.self  must  also  Ix’ 
protected  from  damage.  Redundant  networking  can  provide  a  .secondary'  network  as  a  backup  when  the 
primary  network  fails.  Alternate  routing  can  be  used  when  a  portion  of  the  network  is  lost  but  alternate 
routes  still  exist.  Regardless  of  the  method  used  to  assure  network  integrity,  the  application  program  must 
not  be  affected  by  any  modifications  to  interfaces,  routing  techniques,  or  other  mechanisms  made  by  the 
network  management  software.  Likcwi.se,  the  application  program  must  not  rely  on  specific  network  in¬ 
tegrity  charactenstics  such  as  specific  functionality  or  u.se  of  the  pnmary  (or  secondary )  network. 

CommuniCiUion.s  Security 

Communications  security  (CO.MSEC)  is  a  senous  concern  in  networks  handling  classified  data  and 
having  public  access.  COMSEC  is  not  a  problem,  however,  in  a  shipboard  environment  because  of  the 
phvsical  security  provided  by  isolation  from  other  networks.  Damage  control  .sensor  infomiation  is  gener¬ 
ally  not  of  a  classified  nature  and  therefore  requires  no  secunty  measures,  hut  as  DC  infomiation  sy  stems 
become  more  computen/t,d.  some  level  of  security  will  be  required.  When  integrated  with  other  ship  sys¬ 
tems  that  handle  both  classified  and  unclassified  infomiation.  multilevel  secunty  becomes  a  problem. 
Multilevel  security,  and  COMSEC  in  general,  can  be  considered  a  network  management  function,  and  as 
such  must  not  require  or  pemiit  any  interaction  w  iih  DC  application  programs.  Other  .security-related  func¬ 
tions  such  as  sy  stem  and  application  log-m  and  the  display  of  security  classification  bars  on  the  operators 
console  as  desenbed  in  die  Depanment  of  Defen.sc  Human  Computer  Interface  Style  Guide  18]  must  he 
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iransparent  lo  tlio  underlying  application.  Although  operator  interfacing  may  be  required  for  password  entry 
or  operator  identification,  these  functions  must  be  performed  without  affecting  the  application  program. 

COMPUTER  ARCHITECTURE  ISSUES 

New  types  uf  DC  equipment  will  invariably  be  implemented  on  a  vanety  of  computer  sy.stcms  with  dif¬ 
ferent  processor  architectures.  Because  different  processors  use  different  byte-ordering  schemes  for  multi- 
byte  quantities,  it  is  important  to  define  the  .scheme  to  be  used  when  interprocessor  communication  is  being 
[X'rfomu'd  over  a  network.  When  the  most  significant  byte  of  a  multibyte  quantity  is  tran.smitted  first  in  a 
serial  stream,  it  is  referred  to  as  big-endian  byte  order.  When  the  least  significant  byte  is  transmitted  first,  it 
IS  called  little-endian.  Some  computers  with  byte-addressable  memory  use  big-endian  order  internally, 
while  others  use  little-endian.  If  one  type  of  byte  ordering  is  used  for  data  transmission  and  the  other  type 
IS  used  internally,  byte  swapping  must  be  perfomicd  to  handle  tlic  data  correctly.  The  original  design  ot  the 
.K  Windows  protocol  [‘q  circumvents  the  byte  swapping  problem  by  providing  separate  network  access 
connection  ports  for  each  byte  order.  A  simpler,  more  suitable  approach  for  damage  control  systems  is  to 
provide  the  byte  order  information  within  the  data  packet,  similar  to  later  versions  of  X  Windows  1 101 
This  approach  allows  seasor  interface  units  (SIUs)  to  handle  data  in  their  most  efficient  manner  and  puts  the 
burden  of  byte  swapping  on  the  operator’s  workstation  or  console  device.  Since  these  workstations  w  ill 
have  powerful  processing  capabilities,  minimal  impact  is  incurred. 

Word  alignment  is  another  computer  architecture  issue  that  must  be  addressed.  Information  being 
passed  by  the  protocol  may  contain  data  comprising  16-  and  32-bit  quantities.  Some  computers  require  16- 
bil  quantities  to  be  aligned  on  16-bit  boundaries,  and  32-bit  quantities  to  be  aligned  on  32-bil  boundanes  in 
memory.  To  allow'  efficient  implementations  of  the  protocol  on  these  machines,  blocks  of  data  must  always 
be  multiples  of  32  bits,  and  all  16-  and  32-bit  quantities  witltin  a  block  must  be  aligned  on  16-  and  32-bii 
boundaries,  respectively.  Tliis  restriction  poses  no  problem  for  smaller  S-bil  machines  and  creates  only  a 
smtill  overhead  in  memory  and  block  size.  Performance  increa.ses  in  larger  machines  may  be  significant 
w  ith  this  approach. 

PROTOCOL  LSSUES 

Several  significant  issues  must  be  considered  in  the  design  of  a  damage  control  systems  protocol.  To 
provide  sensor-,  interface-,  and  console-specific  message  passing,  a  coherent  addressing  scheme  must  be 
established.  A  method  of  prioritizing  data  must  be  established  to  permit  quick  handling  of  mission-critical 
information.  To  define  the  functionality  of  the  protocol,  the  types  of  data  packets  permitted  and  their 
relationships  to  each  other  must  be  specified.  Provisioas  for  interaction  with  networked  databa.ses  and  othci 
future  capabilities  must  be  made. 

Addressing 

In  a  networked  environment,  an  addressing  scheme  must  be  establi.shcd  that  can  provide  both 
individual  and  group  addresses.  Shipboard  damage  control  systems  must  be  able  to  access  infonnaiion 
pertaining  to  individual  sensors,  consoles,  or  interface  multiplexers.  The  use  of  a  16-hit  address  field 
provides  65.536  ind'  'idual  addresses,  but  some  allowance  must  be  made  for  different  addressing  modes 
A  broadcast  address  must  be  available  to  transfer  the  information  in  a  single  message  to  all  devices  on  the 
network.  Typically,  the  address  composed  of  all-ones  bits  (i.e.,  the  address  with  a  value  of  65,535 1  is  re 
serv'ed  for  a  broadcast  address.  The  all-z.cros  address  is  sometimes  used  as  an  alternate  broadcast  address, 
but  this  address  may  cause  problems  when  an  uninitialized  device  incorrectly  uses  zero  as  its  own  address 
To  prevent  this  problem,  the  all-zero^'  address  is  an  inval  '  address,  and  the  all-ones  address  is  used  to 
conform  lo  normal  networking  practices. 
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Being  able  to  address  a  group  of  devices  with  a  single  address  is  often  convenient  and  can  reduce  the 
amount  of  network  traffic  considerably.  Addresses  in  the  32,768  through  65,534  range  are  reserved  for 
group  addresses.  This  allows  maximum  flexibility  in  the  assignment  of  both  group  and  individual  ad¬ 
dresses.  Group  addressing  would  typically  be  used  to  address  all  consoles,  all  devices  on  the  main  deck, 
all  devices  in  engineering  spaces,  all  smoke  detectors,  or  any  other  grouping  that  may  be  used  to  make  sys¬ 
tem  management  more  efficient. 

Multiplexers  that  provide  interfaces  to  several  devices  are  assigned  a  range  of  addresses  to  respond  to. 
The  number  of  addresses  used  is  equal  to  the  maximum  number  of  interfaces  supported  by  the  multiplexer 
plus  two  additional  addresses.  The  first  address  in  the  multiplexer  range  is  assigned  to  the  multiplexer  con¬ 
troller  (not  to  any  attached  device),  and  the  last  device  in  the  range  signifies  all  devices  attached  to  the  multi¬ 
plexer  (effectively  a  multiplexer  group  address).  The  add; esses  for  the  devices  attached  to  the  multiplexer 
are  formed  by  adding  the  multiplexer  address  to  the  number  of  the  interface  used  by  the  device. 

Priority  Service 

The  speed  at  which  a  re.sponse  to  an  event  is  required  varies  widely  for  DC  systems.  Some  events  are 
simply  notification  of  a  change  in  status  of  a  device,  such  as  a  hatch  being  opened,  while  others  may 
threaten  the  survivabiliiy  of  the  ship,  such  as  a  fire  being  detected  in  a  magazine.  Prioritized  service  for 
messages  is  required  to  prevent  critical  messages  from  bemg  delayed  by  insignificant  ones  already  in  the 
message  processing  queue.  Low  priority  is  assigned  to  messages  that  do  not  affect  the  normal  operations  of 
the  ship,  such  as  messages  associated  with  information  logging.  Normal  priority  is  used  for  normal  DC 
system  operations  such  as  changing  sensor  configurations.  Warning  priority  is  used  to  alert  DC  personnel 
to  a  problem  that  may  lead  to  an  emergency  condition.  Color  displays  would  normally  present  this  informa¬ 
tion  as  a  “yellow  alert”.  Alarm  priority  means  that  an  emergency  condition  (a  “red  alert”)  that  requires  im¬ 
mediate  action  has  occurred.  Each  message  contains  a  priority  field  that  indicates  the  criticality  of  the  infor¬ 
mation  it  contains. 

Packet  Types 

The  functionality  of  the  protocol  is  determined  by  the  types  of  data  packets  used  and  their  association 
to  each  other.  Packets  are  used  to  send  commands,  requests,  replies,  notifications,  and  acknowledgments 
between  devices  on  the  network. 

A  command  packet  instructs  a  device  to  take  a  particular  action.  Commands  arc  generally  sent  from  an 
operator’s  console  to  an  SIU  to  configure,  activate,  deactivate,  modify,  or  test  sensors,  interfaces,  mul¬ 
tiplexers,  or  associated  equipment.  Commands  may  also  be  sent  from  one  console  to  another  to  assign 
operational  responsibility,  reconfigure  console  functions,  or  pass  pertinent  information.  Commands  arc  a 
unilateral  transfer  from  the  source  to  the  destination,  and  neither  require  nor  expect  any  reply.  An  example 
of  a  command  from  a  console  to  an  SIU  would  be  to  set  the  alarm  threshold  of  a  heat  sensor  to  a  particular 
temperature. 

A  request  packet  solicits  information.  Requests  are  typically  sent  from  an  operator’s  console  to  an  SIU 
to  determine  the  current  value  of  a  sensor  reading,  an  interface  configuration,  or  the  operational  status  of  a 
particular  device.  Requests  may  also  be  sent  between  consoles  to  solicit  operational  control,  interoperator 
messages,  or  system  configuration  status.  All  request  packets  require  a  reply  from  the  device  to  which  the 
request  was  addressed.  A  time-out  feature  is  used  with  all  request  packets.  The  time-out  period  is  begun 
when  a  request  is  issued,  and  if  no  reply  is  received  before  the  expiration  of  the  time-out  period,  an  ex¬ 
ception  function  is  executed.  This  exception  function  is  typically  the  issuance  of  an  alert  message  to  the 
operator  indicating  that  no  reply  was  received  to  a  request.  An  example  of  a  request  from  a  console  to  an 
SIU  would  be  to  request  the  current  temperature  of  a  heat  sensor. 
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A  reply  packet  provides  the  information  solicited  in  a  request  packet.  The  purpose  of  the  reply  packet 
is  to  cancel  the  time-out  function  initiated  by  the  issuance  of  a  request  packet.  An  example  of  a  reply  from 
an  SIU  to  a  console  would  be  to  report  the  current  temperature  of  a  heat  sensor. 

A  notification  packet  provides  unsolicited  information  to  a  console.  These  packets  are  usually  initiated 
by  changes  in  status,  alarm  conditions,  or  other  events  that  require  operator  notification  or  action. 
Notification  packets  require  an  acknowledgment  from  a  console.  This  acknowledgment  can  be  automatic 
(through  software  control),  or  may  require  operator  action  to  initiate  it.  A  time-out  feature,  similar  to  the 
one  used  with  request  packets,  is  used  by  the  initiating  device  to  assure  delivery  of  the  notification.  Upon 
expiration  of  the  time-out  period,  the  notification  is  issued  again,  assuring  response  to  an  alarm  condition  at 
an  operator’s  console.  An  example  of  a  notification  packet  from  an  SIU  to  a  console  would  be  to  report  a 
high-tcmpcrature  alarni  condition  from  a  heat  detector. 

An  acknowledgment  packet  acknowledges  receipt  of  a  notification  packet.  The  purpose  of  the 
acknowledgment  packet  is  to  cancel  the  time-out  function  initiated  by  the  issuance  of  a  notification  packet. 
An  example  of  an  acknowledgment  packet  from  a  console  to  an  SIU  would  be  to  acknowledge  a  high- 
temperature  alarm  condition  from  a  heat  sensor. 

Packet  structure 

Each  packet  is  structured  to  provide  certain  message  processing  functions  in  Lhe  packet  header,  along 
with  variable  length,  variable  context  data  in  the  message  block.  The  header  contains  the  priority,  packet 
type  number,  protocol  version  number,  flags  for  configuration  indicators,  addressing  information,  and  a 
unique  packet  identification  number  (Fig.  6). 
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Fig. 6  —  Header  information 

The  first  byte  of  the  header  contains  the  packet  priority  and  type  number.  The  most  significant  fou 
bits  of  the  first  byte  provide  the  packet  priority,  and  the  least  significant  four  bits  are  the  packet  type.  The 
second  byte  of  the  header  contains  flags  that  convey  information  such  as  byte  order,  along  with  the  protocol 
version  number  of  the  device  sending  the  packet.  Flags  are  single-bit  indicators  of  the  presence  of  a 
condition  if  the  bit  value  is  one,  and  the  absence  of  the  condition  if  the  bit  value  is  zero.  The  minimal 
configuration  presented  here  requires  at  least  the  byte  order  flag.  A  value  of  zero  for  the  byte  order  flag 
indicates  that  little-endian  byte  ordering  is  used,  and  a  value  of  one  indicates  big-endian.  The  protocol 
version  number  may  be  used  as  upgrades,  and  revisions  of  the  protocol  provide  enhancements  that  may  not 
be  supported  by  older  devices.  Table  1  shows  the  values  used  for  the  first  two  header  bytes.  The 
remainder  of  the  header  is  composed  of  thrc«.  1 6-bit  quantities  that  convey  the  source  address,  destination 
address,  and  a  unique  identifier  number  for  the  packet.  The  unique  identifier  is  generated  in  the  source 
device  for  each  new  packet  transmission,  but  repeated  packets  that  are  sent  because  of  time-outs  use  the 
original  identifier,  thereby  preventing  multiple  alarms  fora  single-notification  packet. 
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Table  1  —  Priority,  Packet  Type,  and  Configuration  Flag  Values 
Used  in  the  First  Byte  of  the  Header 


PrioritY  values 

0 

Low 

1 

Normal 

2 

Warning 

3 

Alarm 

Packet  type  values 

0 

Reserved 

1 

Command  packet 

2 

Request  packet 

3 

Reply  packet 

4 

Notification  packet 

5 

Acknowledgment  packet 

6-15 

Unassigned 

Flag 

values 

FI 

Big-endian  byte  order 

F2-F4 

Unassigned 

The  message  block  that  follows  the  header  is  composed  of  two  16-bit  fields  that  provide  the  function 
code  for  the  data  and  the  length  (in  32-bit  longwords)  of  the  appended  data  block,  followed  by  the  variable 
length  data  (Fig.  7).  The  data  being  transferred  depends  on  the  function  and  format  of  the  information,  and 
can  be  any  length,  but  the  length  of  the  packet  is  stilt  required  to  be  a  multiple  of  32  bits.  Any  excess  bytes 
appended  to  the  block  to  meet  this  requirement  are  ignored.  Note  that  zero  is  a  valid  length  for  the  data 
block,  since  some  function  codes  provide  no  amplifying  data. 

Function  Data  block 

code  length 


variable  length 


Data 

block 


Fig.  7  —  Message  block  information 

The  function  codes  indicate  the  action  to  take,  information  to  transfer,  or  type  of  notification  to  act  on, 
and  provide  the  mechanism  through  which  consoles  and  SIUs  interact.  These  function  codes  will  be  de¬ 
fined  as  required  to  include  the  capabilities  of  sensors  and  interfaces  under  development.  Command  func¬ 
tion  codes  sent  from  consoles  to  SIUs  include  instructions  such  as  set  alarm  value,  reset  interface,  enable 
built-in  test  (BIT)  checking,  disable  alarm,  activate  device,  or  calibrate  sensors.  Command  functions 
transmitted  between  consoles  include,  for  example,  assume  operational  command,  display  operator  mes¬ 
sage,  update  console  database,  and  switch  to  alternate  network  interface.  Request  function  codes  sent  from 
consoles  to  SIUs  perform  queries  of  data  such  as  sensor  values,  alarm  settings,  interface  status,  BIT  test  re- 
sulLs,  and  number  of  active  sensor  interfaces.  Interconsole  requests  include  queries  for  system  configura¬ 
tion  status,  interoperator  messages,  and  database  information.  Notification  packets  have  function  codes  for 
events  such  as  alarm  threshold  exceeded,  device  control  assumed  by  local  control  panel,  interface  fault  de¬ 
tected,  and  power-up  initialization  complete. 
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A  well-defined,  comprehensive  assignment  of  function  codes  is  required  to  have  an  effective  interac¬ 
tion  between  the  sensors,  SIUs,  and  consoles.  Because  current  sensors  provide  little  more  than  a  pass/fail 
indication  of  their  alarm  status,  and  development  of  advanced  sensors  is  in  its  infancy,  the  assignment  of 
function  codes  to  devices  or  interfaces  would  be  premature  at  this  time.  These  assignments  will  be  defined 
after  the  development  of  the  sensors  and  interfaces  has  progressed. 

Database  Interaction 

Databases  that  allow  data  retrieval  via  network  access  have  become  an  efficient  and  convenient  way  of 
obtaining  information  without  requiring  the  data  to  be  encapsulated  within  an  application  program.  This  al¬ 
lows  the  database  information  to  change  as  required,  without  changing  the  application  programs  that  use  the 
information.  Application  programs  with  encapsulated  databases  require  software  upgrades  on  all  worksta¬ 
tions  that  run  the  programs  when  the  data  change,  but  with  networked  databases,  none  of  the  application 
programs  require  modification  if  the  data  change.  Future  shipboard  systems  will  have  databases  for  engi¬ 
neering  drawings,  DC  diagrams,  equipment  status,  maintenance  records,  duty  rosters,  and  other  informa¬ 
tion  that  would  be  helpful  to  DC  personnel.  The  ability  to  transfer  these  data  must  be  provided  for  in  the 
interface  protocol. 

Networked  databases  will  be  based  on  commercial  products  with  standard  access  techniques  and 
protocols  such  as  structured  query  language  (SQL).  These  protocols  should  be  used  for  retrieval  of 
database  information,  and  knowledge  of  the  protocols  must  be  included  in  application  programs  that  require 
database  interaction.  Access  control  such  as  passwords  or  other  security  measures  that  may  be  used  by 
these  databases  can  be  accommodated  with  a  request-and-reply  verification  procedure  prior  to  allowing  data 
retrieval.  Functions  codes  to  support  these  actions  will  be  added  to  the  protocol  as  networked  database  ac¬ 
cess  is  made  available  on  ships. 

FUTURE  CONSIDERATIONS 

The  most  important  attribute  of  the  protocol  needed  to  meet  future  requirements  is  the  ability  to  expand 
its  capabilities  to  support  new  equipment  designs,  technologies,  or  techniques.  Expandability  of  the  proto¬ 
col  has  been  included  in  the  design  through  the  use  of  functions  codes  and  version  numbers.  As  new 
equipment  is  developed  with  features  and  functions  that  are  unique  to  it,  new  function  numbers  will  be 
added  to  the  protocol  to  support  them. 

To  keep  the  complexity  of  the  protocol  low,  function  codes  are  generally  designed  to  be  as  generic  as 
possible.  For  example,  a  request  for  a  sensor  reading  can  be  used  for  virtually  all  sensors,  but  the 
interpretation  of  the  data  is  dependent  on  the  particular  sensor.  The  sensor  reading  may  be  given  in  degrees 
Fahrenheit  for  a  heat  sensor,  percent  per  foot  obscuration  for  a  smoke  detector,  inches  of  depth  for  a  flood 
detector,  type  of  combustion  material  for  a  flame  detector,  or  a  simple  opcn/closcd  indication  for  a  hatch 
closure  sensor.  In  each  case  the  reporting  mechanism  (the  protocol  packet  type  and  function  code)  is  the 
same,  even  though  the  data  have  entirely  different  meanings. 

The  use  of  protocol  version  numbers  is  specifically  designed  to  determine  the  capabilities  of  specific 
devices  as  they  are  upgraded  and  enhanced.  Early  versions  of  many  devices  may  report  readings  as  simply 
above  or  below  a  fixed  threshold  setting,  while  later  versions  will  provide  the  actual  sensor  value.  Version 
numbers  are  used  to  determine  if  the  value  provided  uses  the  format  specified  for  the  older  equipment  or  the 
newer  equipment.  The  capability  of  a  particular  device  to  respond  to  a  particular  function  code  is  deter¬ 
mined  by  its  version  number.  When  new  function  codes  are  added  to  the  protocol,  a  corresponding  new 
version  number  is  created.  Older  equipment  will  be  backward  compatible,  but  it  will  not  have  the  capability 
to  respond  to  the  newer  function  codes. 
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CONCLUSIONS 

Damage  control  systems  are  evolving  rapidly  into  large,  complex  systems  with  a  potential  of  collecting 
vast  quantities  of  detailed  information.  To  handle  this  information  effectively,  DC  systems  will  be  trans¬ 
formed  from  their  traditional  centralized  architectures  to  more  efficient  and  more  survivable  distributed 
architectures.  A  coherent  method  of  transferring  DC  information  across  these  distributed  networks  is 
required  in  the  form  of  an  interface  protocol  that  can  be  used  by  DC  systems  and  personnel  to  quickly 
asse.ss  damage  situations  and  initiate  quick  corrective  actions. 

In  this  report,  we  have  described  the  requirements  of  the  mechanism  through  which  advanced  damage 
control  sensors  and  consoles  interact,  and  have  addressed  issues  that  may  impact  the  use  of  the  protocol  in 
various  system  configurations.  The  impact  of  networks  of  various  media  types,  topological  structures,  data 
transmission  speeds,  and  management  techniques  has  been  discussed  with  respect  to  their  use  as  an  under¬ 
lying  structure  upon  which  the  interlace  protocol  is  built.  Careful  attention  has  been  taken  to  address  cur¬ 
rent  and  future  computer  system  architecture  requirements  in  the  design  of  the  protocol  structure.  Specific 
protocol  requirements  for  device  and  group  addressing,  prioritized  service,  and  database  access  have  also 
been  described.  Details  of  specific  requirements  for  the  ability  to  send  commands,  requests,  replies,  notifi¬ 
cations,  and  acknowledgments  between  devices  has  been  presented,  and  the  method  for  expanding  the 
protocol  to  meet  the  needs  of  the  future  has  been  given.  The  concepts  and  recommendations  presented  in 
this  report  will  provide  a  fast  and  effective  way  for  complex  damage  control  systems  to  be  managed  and 
operated  quickly  and  efficiently. 
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